home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 7246 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.5 KB  |  95 lines
  1. Newsgroups: comp.lang.c++
  2. Path: netcom.com!marnold
  3. From: marnold@netcom.com (Matt Arnold)
  4. Subject: Re: Is there a standard for * and & placement style?
  5. Message-ID: <marnoldDn63vB.H6n@netcom.com>
  6. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  7. References: <3128BD31.4AF8@wildfire.com> <marnoldDn27q9.Is0@netcom.com> <4gckd5$bc7@clarknet.clark.net>
  8. Date: Thu, 22 Feb 1996 08:06:46 GMT
  9. Sender: marnold@netcom10.netcom.com
  10.  
  11. gusty@clark.net (Harlan Messinger) writes:
  12.  
  13. >Matt Arnold (marnold@netcom.com) wrote:
  14. >: My personal preference is Form 1, and I have a logical reason:  It
  15. >: seems to me that that "pointer-ness" (*) or "reference-ness" (&) is
  16. >: certinaly part of the variable *type*, not part of the variable.  It
  17. >: therefore seems logical to associate * or & with type identifier 
  18. >: rather than the variable name.  For me, this creates a distinct 
  19. >: visual separation between types and variables.
  20.  
  21. >I agree with you that I would _like_ the * and the & to be appended to 
  22. >the base type. However, the syntax of pointer and reference type 
  23. >declarations itself associates the * and the & with the variable names, 
  24. >as can be seen when multiple variables are declared on the same line.
  25.  
  26. >    char* p, q;
  27.  
  28. As a rule, I never declare multiple variables on one line.  I prefer to
  29. program so that each line (if possible) only deals with a single concept.
  30. A single branch, a single function call, a single variable declaration,
  31. etc..  I dislike the ? operator, if you see what I mean, although I use
  32. it occasionally.
  33.  
  34. Anyway, never writing something like the above declaraion of p and q is
  35. due to this rule I use.
  36.  
  37. >may appear to declare two variables, each a (char*), but that is not the 
  38. >case. Instead, p is (char*) and q is char. To get both of them to be 
  39. >(char*), we need
  40.  
  41. >    char *p, *q;
  42.  
  43. >Adding more complexity,
  44.  
  45. >    char a, b, *c, *d, &e = a;
  46.  
  47. >declares a and b as char, c and d as (char*), and e as (char&).
  48.  
  49. Yuck!  This kind of confusion is exactly why I don't use such forms.
  50.  
  51. >I think the syntax is dumb in the first place. One declaration statement 
  52. >should declare variables of one type. I think
  53.  
  54. >    char* a, b, c;
  55.  
  56. >should declare three (char*) variables. If someone also wants a char 
  57. >variable d, then that should be on two lines:
  58.  
  59. That would be better, but I still subscribe to the "one concept per
  60. line" theory of programming and would never declare three variables on
  61. a single line.  
  62.  
  63. I'd prefer...
  64.  
  65.    char* a;
  66.    char* b;
  67.    char  c;
  68.    char& d;
  69.  
  70. ...to any other way.  You simply can't make a mistake, misinterpret
  71. or confuse variable declarations with this format as you can with the
  72. others.  
  73.  
  74. Some may think "one concept per line" to be silly, but I've found it
  75. also makes maintaining code a bit simpler (for less intra-line edits, 
  76. and more line-by-line edits).  Output of diff programs is also less 
  77. cluttered.
  78.  
  79. Just because the langauge allows a particular syntax does not mean
  80. you have to use it or structure your coding practices around it.  I
  81. simply don't use mutli-variable declarations and considerations like
  82. you point out above have never been a source of trouble for me.
  83.  
  84. Regards,
  85. -------------------------------------------------------------------------
  86. Matt Arnold                       |        | ||| | |||| |  | | || ||
  87. marnold@netcom.com                |        | ||| | |||| |  | | || ||
  88. Boston, MA                        |      0 | ||| | |||| |  | | || ||
  89. 617.389.7384 (h) 617.576.2760 (w) |        | ||| | |||| |  | | || ||
  90. C++, MIDI, Win32/95 developer     |        | ||| 4 3 1   0 8 3 || ||
  91. -------------------------------------------------------------------------
  92.  
  93.  
  94.  
  95.